Enabling data access by external cloud-based analytics system

ABSTRACT

Methods, systems, and computer-readable storage media for retrieving metadata associated with data stored within a database system of an enterprise, the metadata being provided in a first format and being used by the first system to store and access the data, providing a document including the metadata provided in an interoperable format, processing, by a deployer, the document to provide analytics engine metadata in a second format, the analytics metadata being stored in the second system and being consumable by the DB-based analytics engine to access the data from the database system of the enterprise, and retrieving, by the DB-based analytics engine, the data from the database system of the enterprise based on the analytics metadata to provide analytics data based on the data.

BACKGROUND

An enterprise can use multiple systems for storing and processing data.For example, an enterprise can use a system that stores data in adatabase system and provides metadata that defines how the data isstored and how the data is accessed. Analytics systems have beenintroduced that provide advanced analytics capabilities and improveddata processing performance as compared to that provided by othersystems, such as a system within which the enterprise stores andmaintains its data. Such analytics systems can include cloud-basedanalytics systems that include an analytics engine that is executeddirectly within the underlying database system. Such an analytics enginecan be referred to as a database (DB) analytics engine (DB-basedanalytics engine).

To provide a unified user experience for enterprises, it is desirable toconnect systems within which data of the enterprise is stored to theDB-based analytics engine. In this manner, an enterprise is able toleverage the more sophisticated and resource-efficient analyticsprovided by an analytics system through the DB-based analytics engine.Traditional techniques to achieve this include, for example, providing aso-called live connection using an online analytical processing (OLAP)processor, and through the DB-based analytics engine using so-calledcalculation views. However, such traditional techniques havedisadvantages. For example, calculation views used in the databasesystem access causes severe performance issues, because of thecomplexity and missing metadata, as well as other disadvantages.

SUMMARY

Implementations of the present disclosure are directed to enabling dataprovided in a first system to be accessed and processed by an analyticsengine of a second system. More particularly, implementations of thepresent disclosure transform metadata (that is used by the first systemto store and access data) from a first format to a second format throughan intermediate format to enable the analytics engine of the secondsystem to access the data for analytics processing.

In some implementations, actions include retrieving metadata associatedwith data stored within a database system of an enterprise, the metadatabeing provided in a first format and being used by the first system tostore and access the data, providing a document including the metadataprovided in an interoperable format, processing, by a deployer, thedocument to provide analytics engine metadata in a second format, theanalytics metadata being stored in the second system and beingconsumable by the DB-based analytics engine to access the data from thedatabase system of the enterprise, and retrieving, by the DB-basedanalytics engine, the data from the database system of the enterprisebased on the analytics metadata to provide analytics data based on thedata. Other implementations of this aspect include correspondingsystems, apparatus, and computer programs, configured to perform theactions of the methods, encoded on computer storage devices.

These and other implementations can each optionally include one or moreof the following features: the metadata is retrieved in response to thedata being marked as to be accessible to the DB-based analytics engine;the metadata is retrieved in response to determining that a change tothe metadata has occurred; the DB-based analytics engine is executedwithin the database system of the enterprise; the DB-based analyticsengine is executed within a cloud-based database system that accessesthe database system of the enterprise; the deployer is provided withinthe database system of the enterprise; and the interoperable formatcomprises core schema notation (CSN).

The present disclosure also provides a computer-readable storage mediumcoupled to one or more processors and having instructions stored thereonwhich, when executed by the one or more processors, cause the one ormore processors to perform operations in accordance with implementationsof the methods provided herein.

The present disclosure further provides a system for implementing themethods provided herein. The system includes one or more processors, anda computer-readable storage medium coupled to the one or more processorshaving instructions stored thereon which, when executed by the one ormore processors, cause the one or more processors to perform operationsin accordance with implementations of the methods provided herein.

It is appreciated that methods in accordance with the present disclosurecan include any combination of the aspects and features describedherein. That is, methods in accordance with the present disclosure arenot limited to the combinations of aspects and features specificallydescribed herein, but also include any combination of the aspects andfeatures provided.

The details of one or more implementations of the present disclosure areset forth in the accompanying drawings and the description below. Otherfeatures and advantages of the present disclosure will be apparent fromthe description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 depicts an example architecture that can be used to executeimplementations of the present disclosure.

FIG. 2 depicts an example conceptual architecture in accordance withimplementations of the present disclosure.

FIG. 3 depicts another example conceptual architecture in accordancewith implementations of the present disclosure.

FIGS. 4A-4C depict example screen-shots for a query design-time within adata warehouse (DW) system.

FIG. 5 depicts an example process that can be executed in accordancewith implementations of the present disclosure.

FIG. 6 is a schematic illustration of example computer systems that canbe used to execute implementations of the present disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Implementations of the present disclosure are directed to enabling dataprovided in a first system to be accessed and processed by an analyticsengine of a second system. More particularly, implementations of thepresent disclosure transform metadata (that is used by the first systemto store and access data) from a first format to a second format throughan intermediate format to enable the analytics engine of the secondsystem to access the data for analytics processing.

Implementations can include actions of retrieving metadata associatedwith data stored within a database system of an enterprise, the metadatabeing provided in a first format and being used by the first system tostore and access the data, providing a document including the metadataprovided in an interoperable format, processing, by a deployer, thedocument to provide analytics engine metadata in a second format, theanalytics metadata being stored in the second system and beingconsumable by the DB-based analytics engine to access the data from thedatabase system of the enterprise, and retrieving, by the DB-basedanalytics engine, the data from the database system of the enterprisebased on the analytics metadata to provide analytics data based on thedata.

Implementations of the present disclosure are described in furtherdetail herein with reference to products, services, and infrastructuresprovided by SAP SE of Walldorf, Germany. It is contemplated, however,that implementations of the present disclosure can be realized with anyappropriate products, services, and/or infrastructures provided by oneor more providers.

To provide further context for implementations of the presentdisclosure, and as introduced above, an enterprise can use multiplesystems for storing and processing data. For example, an enterprise canuse a system that stores data in a database system and provides metadatathat defines how the data is stored and how the data is accessed. Anexample system includes, without limitation, a data warehouse (DW),which can be described as a system used for storing data, generatingreports, and executing data analytics. A DW can be considered a centralrepository of data integrated from disparate sources and includesmetadata that defines how the data is stored and how the data isaccessed. For example, the data can be stored in a particular schema(e.g., star schema, discussed below). A DW can store a significantamount of data (e.g., multiple terabytes of data). In some scenarios, aDW is provided as an on-premise system, such that the DW is at leastpartially managed by the enterprise, for which the DW is established.

By way of non-limiting example, an example DW includes SAP BusinessWarehouse (BW) provided by SAP SE of Walldorf, Germany. SAP BW can bedescribed as a model-driven data warehousing product based on the SAPNetWeaver ABAP platform. SAP BW collects, transforms and stores datagenerated in SAP and non-SAP applications and makes the data accessiblethrough built-in reporting, business intelligence, and analytics tools.In SAP BW, data is accessed using so-called InfoCubes, each InfoCubebeing made up of a set of InfoObjects, which include characteristics(e.g., master data with their attributes and text descriptions) and keyfigures. An InfoObject can be described as a type of InfoProvider, whichis a data object that is created and used to run queries. An InfoCube isstructured using a star schema, which includes a fact table thatcontains key figures for the InfoCube, and several dimension tablessurround the fact table. The fact table and dimension tables are bothrelational database tables that are stored in the underlying databasesystem.

In some examples, a DW (such as SAP BW) includes an analytics enginethat enables data to be retrieved from the underlying database system,executes analytics on the retrieved data, and provides analytics resultsto a client. For example, the analytics engine (also referred to hereinas the DW analytics engine, or server-based analytics engine) isexecuted within an application server. In some examples, the applicationserver receives a request from a client (e.g., a computing device incommunication with the application server), and interprets the requestbased on metadata to determine which data to retrieve from the database.The application server queries the database system using a querylanguage (e.g., (SQL)), and receives data (e.g., hundreds, thousands ofrecords) responsive to the query from the database system. Theapplication server processes the received data using the server-basedanalytics engine and provides analytics data to the client. This processcan be referred to as a 3-tiered approach, in which the majority ofprocessing is executed within the application server.

Analytics systems have been introduced that provide advanced analyticscapabilities and improved data processing performance as compared tothat provided by DWs, for example. Such analytics systems can includecloud-based analytics systems that include an analytics engine that isexecuted directly within the underlying database system (e.g., asopposed to a DW analytics engine that executes within an applicationserver). Such an analytics engine is referred to herein as a database(DB) analytics engine (DB-based analytics engine). Accordingly, inresponse to a request from a client, the request is processed by the DBanalytics engine within the database system. Consequently, data storedwithin the database system is directly accessed by the DB-basedanalytics engine for analytics processing within the database system,avoiding transmitting data from the database system for analyticsprocessing (e.g., transmitting data from the database system to anapplication server).

By way of non-limiting example, an example cloud-based analytics systemincludes SAP Analytics Cloud (SAC) provided by SAP SE of Walldorf,Germany. SAC can be described as an all-in-one platform for businessintelligence, planning, and predictive analytics to support enterpriseoperations. In some examples, SAP SAC uses multi-dimensional services(MDS), which provides a DB-based analytics engine. SAP SAC providesrequests to the MDS in a particular protocol (e.g., information access(InA) protocol), which enables more complex data analytics requests tobe formulated and executed (e.g., as compared to data analytics requestssubmitted through the DW).

To provide a unified user experience for enterprises using DWs, it isdesirable to connect the DW to the DB-based analytics engine. In thismanner, an enterprise using a DW is able to leverage the moresophisticated and resource-efficient analytics provided by an analyticssystem through the DB-based analytics engine. Traditional techniques toachieve this include, for example, providing a so-called live connectionusing an online analytical processing (OLAP) processor, and through theDB-based analytics engine using so-called calculation views created bythe DW. However, such traditional techniques have disadvantages. Forexample, calculation views used in the database system access causessevere performance issues, because of the complexity and missingmetadata.

With regard to complexity, view creation is designed for usage bySQL-based tools. Consequently, a calculation view contains many parts,which represent features of the DW that may be used. Often, thecalculation view contains a complex calculation engine scenario withthousands of nodes. For example, available hierarchies are included byexpensive (in terms of resources required to calculate) outer joins,currency conversions are built in, and the like. This leads tosubstantial instantiation, optimization and runtimes. DW, on the otherhand, uses much simpler views—even using SIDs instead of values—and canaccess the data much faster.

With regard to missing metadata, many details of the view internals arenot available as calculation view metadata, which must be used by theDB-based analytics engine. This leads to performance issues. Forexample, measures using the same currency or unit column or constant inthe DW model are shown as different currency/unit columns in the view.The DB-based analytics engine cannot combine these in a singleaggregation, because this may result in incorrect results. Runtimesincrease with the number of measures used. As another example, allavailable hierarchies are included in the created view. Without theappropriate metadata, hierarchies requested in the analytics systemcannot be used. As another example, the view may contain restricted keyfigures with additional filters. The calculation view metadata, however,contains a simple base measure only. Count aggregations, which do notexplicitly request the measure, may return unexpected results, becausethe restricted key figure filter is not applied. Besides theabove-disadvantages, traditional techniques for connecting the DW to theDB-based analytics engine suffer from other drawbacks.

In view of the above context, implementations of the present disclosureenable data provided in a first system to be accessed and processed byan analytics engine of a second system. More particularly, and asdescribed in further detail herein, implementations of the presentdisclosure transform metadata (that is used by the first system to storeand access data) from a first format to a second format through anintermediate format (referred to herein as an interoperable format) toenable the analytics engine of the second system to access the data foranalytics processing.

Implementations of the present disclosure are described in furtherdetail herein with reference to a DW system. It is contemplated,however, that implementations of the present disclosure can be realizedwith any appropriate system that stores data that is to be accessed byanother system.

FIG. 1 depicts an example architecture 100 in accordance withimplementations of the present disclosure. In the depicted example, theexample architecture 100 includes a client device 102, a network 106,and server systems 104, 105. The server systems 104, 105 each includeone or more server devices and databases 108 (e.g., processors, memory).In the depicted example, a user 112 interacts with the client device102.

In some examples, the client device 102 can communicate with the serversystems 104, 105 over the network 106. In some examples, the clientdevice 102 includes any appropriate type of computing device such as adesktop computer, a laptop computer, a handheld computer, a tabletcomputer, a personal digital assistant (PDA), a cellular telephone, anetwork appliance, a camera, a smart phone, an enhanced general packetradio service (EGPRS) mobile phone, a media player, a navigation device,an email device, a game console, or an appropriate combination of anytwo or more of these devices or other data processing devices. In someimplementations, the network 106 can include a large computer network,such as a local area network (LAN), a wide area network (WAN), theInternet, a cellular network, a telephone network (e.g., PSTN) or anappropriate combination thereof connecting any number of communicationdevices, mobile computing devices, fixed computing devices and serversystems.

In some implementations, the server systems 104, 105 each include atleast one server and at least one data store. In the example of FIG. 1,the server systems 104, 105 is intended to represent various forms ofservers including, but not limited to a web server, an applicationserver, a proxy server, a network server, and/or a server pool. Ingeneral, server systems accept requests for application services andprovides such services to any number of client devices (e.g., the clientdevice 102 over the network 106).

In accordance with implementations of the present disclosure, the serversystem 104 can host a DW system operated for enterprise, and the serversystem 105 can be operated by a software provider (e.g., SAP SE) toprovision services for one or more enterprises. In some examples, theserver system 104 and/or the server system 105 hosts a database system,within which data of the enterprise is stored. An example databasesystem includes, without limitation, SAP HANA provided by SAP SE ofWalldorf, Germany. SAP HANA can be described as a data platform thatprocesses transactions and analytics at the same time on any data type,with built-in advanced analytics and multi-model data processingengines. As described in further detail herein, implementations of thepresent disclosure enable data of the DW system to be accessed andprocessed for analytics using the cloud-based analytics system.

FIG. 2 depicts an example conceptual architecture 200 in accordance withimplementations of the present disclosure. In the depicted example, theexample conceptual architecture 200 includes a frontend system 202, abackend system 204, and a cloud services system 206. In general, theexample conceptual architecture 200 depicts an on-premise approach, inwhich a system (e.g., a DW system), a database system, and a DB-basedanalytics engine are provisioned within a server system operated by anenterprise (e.g., the server system 104 of FIG. 1). That is, forexample, the backend system 204 is a backend system of the enterprise.In some examples, the cloud services system 206 is provided by asoftware provider (e.g., SAP SE) on a server system (e.g., the serversystem 105 of FIG. 1).

In some examples, the frontend system 202 can be executed by one or moreclient-side devices (e.g., the client device 102 of FIG. 1) and includesa DW administrator user interface (UI) 210 and an analytics application212 (e.g., provided as part of SAP SAC). The cloud services system 206can be executed by one or more server-side devices (e.g., the serversystem 105 of FIG. 1). In accordance with implementations of the presentdisclosure, the cloud services system 206 includes integration services214, which includes a metadata handler 216 and a deployer 218. Althoughthe integration services 214 is depicted within the cloud service 206,it is contemplated that the integration services 214 can be provisioneddirectly within the backend 204. For example, in some implementations,the metadata handler 216 and the deployer 218 can be provisioned withinthe backend 204 (e.g., on-premise).

In the depicted example, the backend 204 includes a DW system 220,integration services 222, application services 224, and a databasesystem 226. By way of non-limiting example, the DW system 220 can beprovided as at least a portion of SAP BW, introduced above, and theapplication services 224 can be provided as SAP extended applicationservices (XS) provided by SAP SE of Walldorf, Germany. Also by way ofnon-limiting example, the database system 226 can be provided as SAPHANA.

In the example of FIG. 2, the DW system 220 includes a view generator230, a data authorization provider 232, a metadata invalidator 234, anda metadata provider 236. The integration services 222 includes a dataprovisioning agent 238, and the application services 224 includes aprotocol adapter 240 (e.g., for the InA protocol). In some examples, thedata provisioning agent 238 is provided to enable communication (e.g.,using HTTP) between the cloud services 206 provided by the softwareprovider and the backend system 204 of the enterprise provided as anon-premise system.

In the example of FIG. 2, the database system 226 includes anauthorizations store 250, a DW metadata store 252, a facts store 254, amaster data store 256, one or more InfoProvider views 258, and, for eachInfoProvider view 258, one or more InfoObject views 260. The DW metadatastore 252 stores metadata that describes how data is stored and can beaccessed within the database system 226 (e.g., metadata that describescolumns, views, and relationships therebetween).

The facts store 254 stores fact data, which can be described as datathat changes relatively frequently. Example fact data includes, withoutlimitation, sales, revenue, cost, net values, keys (e.g., a keyidentifying a specific customer) and the like. The master data store 256stores master data, which can be described as data that changes lessfrequently (e.g., as compared to fact data). An example of master dataincludes, without limitation, customer data (e.g., name, address,telephone number).

The database system 226 further includes an analytics engine 270 (e.g.,provide as MDS), an analytics engine data access component 272,analytics engine metadata 274, a view cache manager 276, and a viewcache 278. In some examples, the view cache manager 276 monitors views(e.g., InfoProvider views 258, InfoObject views 260) generated withinthe database system 226, and caches views in the view cache 278.Accordingly, the first time a view is requested, the view can begenerated and stored in the view cache 278, and the second time the viewis requested, the view can be provisioned from the view cache 278, ifstill available in the view cache 278. In this manner, computingresources of the backend system 204 can be preserved, because the viewdoes not need to be (re-)generated with each request.

As described in further detail herein, implementations of the presentdisclosure enable the DB-based analytics engine 270 direct access todata stored by the DW system 220 within the database system 226. Thatis, the DB-based analytics engine 270 is able to directly access factsstored in the fact store 254 and master data stored in the master datastore 256. For example, the analytics engine 270 receives a request foranalytics processing from the analytical application 212 and through theapplication services 224. The analytics engine 270 uses the analyticsengine metadata 274 to provide a data access request to access one ormore InfoProvider views 258 and one or more InfoObjects 260. In someexamples, the data access request is received by the analytics enginedata access component 272, which processes the data access request toretrieve data relevant to the request for analytics.

In accordance with implementations of the present disclosure, DWmetadata stored in the DW metadata store 252 is transformed intoanalytics engine metadata that has a format that is consumable by theDB-based analytics engine 270 and that is stored in the analytics enginemetadata store 274. In some implementations, the metadata provider 236retrieves metadata from the DW metadata store 252 that would be neededto access a particular view. The metadata provider 236 transforms themetadata from a first format to an interoperable format. In someexamples, the first format is specific to analytics processing of the DWsystem (e.g., by a server-based analytics engine executed on anapplication server), and the interoperable format is not bound to anyanalytics engine. The interoperable format includes the metadata andexpresses the semantics and intent of the metadata. In some examples,the interoperable format includes core schema notation (CSN) and themetadata is provided within a metadata document (e.g., a Javascriptobject notation (JSON) document). A non-limiting example CSNrepresentation is provided below in Listing 1. In the example of Listing1, there are two references to “MAX_PLUS_MIN,” one in a section“elements” and one in a section “query,” which contain the design-timeinformation in terms of standardized/interoperable “annotations”, e.g.“@EndUserText.label”, “@Aggregation.default.”

In some implementations, the integration services 214 receives themetadata document from the DW system 220 (e.g., in response to an HTTPrequest issued by the integration services 214 to the DW system 220).The metadata handler 216 interprets the metadata document received fromthe DW system 220 and provides the metadata document to the deployer218. In some examples, the metadata stored in the DW system 220 can bedescribed as single entity definitions and their relations to otherentities. One task of the metadata handler 216 is, starting with asingle entity (e.g., the central entity of a star schema), to collectall metadata from the metadata provider, which is required for thedeployer 218 to create the AE/runtime-optimized metadata. This wouldinclude, for example, all related dimension entities,(language-dependent) texts, and hierarchies for a compete star schema.In order to do so, the metadata handler has to have knowledge about thefunctional scope of the deployer. The deployer 218 transforms themetadata from the interoperable format to a second format that isspecific to the analytics engine 270 to provide the analytics metadata.In some examples, the analytics metadata includes data definitionlanguage (DDL) statements (e.g., to create or delete objects within thedatabase system 226) and/or data modification language (DML) statements(e.g., to insert, update or delete data within the database system 226).The analytics metadata is stored in the analytics metadata store 274through the data provisioning agent 238. In this manner, DW metadatafrom the DW metadata store 252 is transformed to provide analyticsengine data stored in the analytics engine metadata store 274, theanalytics engine 270 being able to consume the analytics metadata toretrieve data (e.g., facts, master data) within the database system 226for analytics processing within the database system 226.

A non-limiting example DW representation is provided below in Listing 2.In the example of Listing 2, there are two sub-sections “MAX_PLUS_MIN”one in a section of “DataSourceFields” referring to a deployed databaseruntime artefact (e.g., a SQL view) and another in a section “Measures”(analytics-specific metadata for the MDS runtime).

FIG. 3 depicts another example conceptual architecture 300 in accordancewith implementations of the present disclosure. The example conceptualarchitecture 300 depicts a hybrid approach, in which an enterprise usesa cloud-based data warehouse system that access data stored in anon-premise system of the enterprise. In this manner, cloud-basedfunctionality is provided, while maintaining the data on-premise. Anexample cloud-based data warehouse system includes, without limitation,the SAP Data Warehouse Cloud (DWC) provided by SAP SE of Walldorf,Germany.

In the example of FIG. 3, the example conceptual architecture 300includes the frontend 202, a cloud-based DW (e.g., SAP DWC) 302, and abackend system 204′ (i.e., on-premise system of the enterprise). Thebackend system 204′ includes a DW system 220′, the integration services222, and a database system 226′. The DW system 220′ includes the viewgenerator 230, the data authorization provider 232, the metadatainvalidator 234, and the metadata provider 236. The integration services222 includes the provisioning agent 238. The database system 226′includes the authorizations store 250, the DW metadata store 252, thefacts store 254, the master data store 256, the one or more InfoProviderviews 258, and the one or more InfoObject views 260.

The cloud-based DW includes spaces 304, repositories 306, integrationservices 214′, and a database system 226″. The integration services 214′include the metadata handler 216, the deployer 218, the adapter 240, andan authorization and data privacy component 310. The database system226″ includes authorizations 312, provided as a remote table, one ormore InfoProvider views 258′, provided as respective remote tables, andone or more InfoObject view 260′, provided as respective remote tables(also referred to as virtual tables). In some examples, a remote tableis a technical artefact in the (local) database system, that appears inall usages to be a table, but in fact it points to a table or view inanother database system, which can be referred to as a remote source.The database system 226″ also includes the analytics engine 270, theanalytics engine data access component 272, the analytics enginemetadata 274, the view cache manager 276, and the view cache 278.

As similarly described above with reference to FIG. 2, DW metadatastored in the DW metadata store 252 is transformed into analytics enginemetadata that has a format that is consumable by the DB-based analyticsengine 270 and that is stored in the analytics engine metadata store274. In some implementations, the metadata provider 236 retrievesmetadata from the DW metadata store 252 that would be needed to access aparticular view. The metadata provider 236 transforms the metadata fromthe first format to the interoperable format. In some implementations,the integration services 214′ receives the metadata document from the DWsystem 220 (e.g., in response to an HTTP request issued by theintegration services 214 to the DW system 220′). The metadata handler216 interprets the metadata document received from the DW system 220′and provides the metadata document to the deployer 218. The deployer 218transforms the metadata from the interoperable format to the secondformat that is specific to the analytics engine 270 to provide theanalytics metadata, which is stored in the analytics metadata store 274.In this manner, DW metadata from the DW metadata store 252 istransformed to provide analytics engine metadata stored in the analyticsengine metadata store 274, the analytics engine 270 being able toconsume the analytics metadata to retrieve data (e.g., facts, masterdata) within the database system 226′ for analytics processing withinthe database system 226″.

In some implementations, to trigger transformation of metadata toprovide analytics engine metadata, data within the database system 226,226′ can be identified as being accessible by the analytics engine 270.For example, a user (e.g., an administrator) can access the DW system220, 220′ through the DW administrator UI 210, and can mark data (e.g.,InfoProviders) that are to be accessible to the analytics engine 270.For example, the user can set a flag associated with the data, the flagindicating that the data is to be accessible to the analytics engine270. In some examples, for each InfoProvider marked as to be accessibleto the analytics engine 270, a SQL view is generated with all dimensionsrelevant to the InfoProvider and including navigation attributes andmeasure fields from the InfoProvider. In some examples, only fields ofthe InfoProvider (e.g., dimension-key, measures) are included. Inresponse to data being marked as accessible to the analytics engine 270,the metadata provider 236 can retrieve corresponding metadata from theDW metadata store 252 to transform the metadata and provide theanalytics engine metadata, as described herein.

In some implementations, it can be determined that metadata underlingdata that is to be accessible to the analytics engine 270 has changed.For example, an update to the database system 226, 226′ can result in astructure of data being changed, which also results in the correspondingmetadata being changed. In some examples, the metadata invalidator 234can be provided as a listener that detects a change in metadata of datathat is to be accessible to the analytics engine 270. If a change hasoccurred, the metadata invalidator 234 triggers redeployment of themetadata as analytics engine metadata. That is, for example, themetadata provider 236 can retrieve corresponding metadata from the DWmetadata store 252 to transform the metadata and provide the analyticsengine metadata, as described herein.

For purposes of illustrating implementations of the present disclosure,and without limitation, a brief description and example of the analyticsengine 270 processing a request from the analytical application isprovided and includes how the analytics metadata is used to identify andaccess data (i.e., an end-to-end workflow starting from the analyticsapplication making a request to the MDS). In further detail, theanalytical application request metadata in order to, for example, offerthe selection of dimensions and measures to a user (e.g., in an “editchart” dialogue). In some examples, the MDS reads its privaterepresentation and converts the measures section into the formatspecified for client/server exchange for metadata (which is close to theMDS-internal format). This is part of the runtime optimization: that itonly uses relatively few and cheap (in terms of resources expended toexecute) transformations to prepare the response for a metadata request.The analytical application has a chart definition, for example, with thedimension “Fiscal Year” and the measure “Max+Min,” and sends acorresponding data request to the MDS. The MDS reads the metadata of therequested fields in order to prepare a response to the data request. TheMDS determines that “Fiscal Year” is a dimension and there is acorresponding column in the data source/underlying SQL view, and that“Min+Max” is a measure. In some examples, “Min+Max” can be provided as aformula (e.g., non-SQL default aggregation FORMULA), referring to othermeasures “Min” (with default aggregation MIN) and “Max” (with defaultaggregation MAX). For those measures there are corresponding columns inthe data source.

In some examples, the MDS prepares an execution plan. An exampleexecution plan based on the above example can include first readingMIN(Min) and MAX(max) group by FISCAL_YEAR from the underlying (SQL)data source, and then calculate the formula MAX_PLUS_MIN for each row ofthe result set. In some examples, the MDS executes the execution plan(e.g., by creating a complex SQL request or a transient DB runtimeartefact (“calculation scenario”) for this plan and execute it). The MDSreturns the query result in accordance with the metadata (e.g. valuesfor measure MIN_PLUS_MAX).

FIGS. 4A-4C depict example screen-shots for a query design-time within aDW system. In the examples of FIGS. 4A-4C, the example measureMAX_PLUS_MIN is defined, which is used in the examples of Listing 1 andListing 2 provided herein.

FIG. 5 depicts an example process 500 that can be executed in accordancewith implementations of the present disclosure. In some examples, theexample process 500 is provided using one or more computer-executableprograms executed by one or more computing devices.

A trigger is received (502). For example, a user can mark data storedwithin the database system 226, 226′ as to be accessible to theanalytics engine 270, the trigger being marking of the data. As anotherexample, it can be determined that metadata associated with data storedwithin the database system 226, 226′ that is to be accessible to theanalytics engine 270 has changed, the trigger being changing of themetadata. DW metadata is accessed (504) and a document is providedincluding DW metadata provided in the interoperable format (506). Forexample, in response to the trigger, DW metadata associated with thedata that is to be accessible to the analytics engine 270 is accessed bythe metadata provider 236, which converts the DW metadata to aninteroperable format. In some examples, the interoperable formatincludes CSN.

The document is processed to provide analytics metadata (508). Forexample, the metadata handler 216 receives the document from the DWsystem 220, 220′, and the deployer 218 processes the document to providethe analytics metadata in the second format, such that the analyticsmetadata is consumable by the analytics engine 270 to access the datafrom the database system 226, 226′. The analytics metadata is stored inthe analytics metadata store (510). Data is retrieved from the databasesystem of the enterprise based on analytics metadata (512).

Referring now to FIG. 6, a schematic diagram of an example computingsystem 600 is provided. The system 600 can be used for the operationsdescribed in association with the implementations described herein. Forexample, the system 600 may be included in any or all of the servercomponents discussed herein. The system 600 includes a processor 610, amemory 620, a storage device 630, and an input/output device 640. Thecomponents 610, 620, 630, 640 are interconnected using a system bus 650.The processor 610 is capable of processing instructions for executionwithin the system 600. In some implementations, the processor 610 is asingle-threaded processor. In some implementations, the processor 610 isa multi-threaded processor. The processor 610 is capable of processinginstructions stored in the memory 620 or on the storage device 630 todisplay graphical information for a user interface on the input/outputdevice 640.

The memory 620 stores information within the system 600. In someimplementations, the memory 620 is a computer-readable medium. In someimplementations, the memory 620 is a volatile memory unit. In someimplementations, the memory 620 is a non-volatile memory unit. Thestorage device 630 is capable of providing mass storage for the system600. In some implementations, the storage device 630 is acomputer-readable medium. In some implementations, the storage device630 may be a floppy disk device, a hard disk device, an optical diskdevice, or a tape device. The input/output device 640 providesinput/output operations for the system 600. In some implementations, theinput/output device 640 includes a keyboard and/or pointing device. Insome implementations, the input/output device 640 includes a displayunit for displaying graphical user interfaces.

The features described can be implemented in digital electroniccircuitry, or in computer hardware, firmware, software, or incombinations of them. The apparatus can be implemented in a computerprogram product tangibly embodied in an information carrier (e.g., in amachine-readable storage device, for execution by a programmableprocessor), and method steps can be performed by a programmableprocessor executing a program of instructions to perform functions ofthe described implementations by operating on input data and generatingoutput. The described features can be implemented advantageously in oneor more computer programs that are executable on a programmable systemincluding at least one programmable processor coupled to receive dataand instructions from, and to transmit data and instructions to, a datastorage system, at least one input device, and at least one outputdevice. A computer program is a set of instructions that can be used,directly or indirectly, in a computer to perform a certain activity orbring about a certain result. A computer program can be written in anyform of programming language, including compiled or interpretedlanguages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors ofany kind of computer. Generally, a processor will receive instructionsand data from a read-only memory or a random access memory or both.Elements of a computer can include a processor for executinginstructions and one or more memories for storing instructions and data.Generally, a computer can also include, or be operatively coupled tocommunicate with, one or more mass storage devices for storing datafiles; such devices include magnetic disks, such as internal hard disksand removable disks; magneto-optical disks; and optical disks. Storagedevices suitable for tangibly embodying computer program instructionsand data include all forms of non-volatile memory, including by way ofexample semiconductor memory devices, such as EPROM, EEPROM, and flashmemory devices; magnetic disks such as internal hard disks and removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory can be supplemented by, or incorporated in,ASICs (application-specific integrated circuits).

To provide for interaction with a user, the features can be implementedon a computer having a display device such as a CRT (cathode ray tube)or LCD (liquid crystal display) monitor for displaying information tothe user and a keyboard and a pointing device such as a mouse or atrackball by which the user can provide input to the computer.

The features can be implemented in a computer system that includes abackend component, such as a data server, or that includes a middlewarecomponent, such as an application server or an Internet server, or thatincludes a front-end component, such as a client computer having agraphical user interface or an Internet browser, or any combination ofthem. The components of the system can be connected by any form ormedium of digital data communication such as a communication network.Examples of communication networks include, for example, a LAN, a WAN,and the computers and networks forming the Internet.

The computer system can include clients and servers. A client and serverare generally remote from each other and typically interact through anetwork, such as the described one. The relationship of client andserver arises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherimplementations are within the scope of the following claims.

A number of implementations of the present disclosure have beendescribed. Nevertheless, it will be understood that variousmodifications may be made without departing from the spirit and scope ofthe present disclosure. Accordingly, other implementations are withinthe scope of the following claims.

What is claimed is:
 1. A computer-implemented method for accessing dataprovided in a first system by a database (DB)-based analytics engine ofa second system, the method being executed by one or more processors andcomprising: retrieving data metadata associated with data stored withina database system of an enterprise, the data metadata being provided ina first format and being used by the first system to store and accessthe data, the data metadata describing how data is stored within thefirst system and comprising entity definitions and relationships betweenentities; providing, by a metadata provider executed within the firstsystem, a metadata document including the data metadata provided in aninteroperable format transformed from the first format, theinteroperable format being unbound to any analytics engine; receiving,by integration services executed within a cloud service, the metadatadocument in response to a request issued by the integration services tothe first system; processing, by a deployer of the integration services,the metadata document to provide analytics metadata in a second format,the analytics metadata comprising one or more of data definitionlanguage (DDL) statements and data modification language (DML)statements, the analytics metadata being stored in the second system andbeing specific to the DB-based analytics engine to be consumable by theDB-based analytics engine to access the data from the database system ofthe enterprise; and retrieving, by the DB-based analytics engine, thedata from the database system of the enterprise based on the analyticsmetadata to provide analytics data based on the data.
 2. The method ofclaim 1, wherein the data metadata is retrieved in response to the databeing marked as to be accessible to the DB-based analytics engine. 3.The method of claim 1, wherein the data metadata is retrieved inresponse to determining that a change to the data metadata has occurred.4. The method of claim 1, wherein the DB-based analytics engine isexecuted within the database system of the enterprise.
 5. The method ofclaim 1, wherein the DB-based analytics engine is executed within acloud-based database system that accesses the database system of theenterprise.
 6. The method of claim 1, wherein the deployer is providedwithin the database system of the enterprise.
 7. The method of claim 1,wherein the interoperable format comprises core schema notation (CSN).8. A non-transitory computer-readable storage medium coupled to one ormore processors and having instructions stored thereon which, whenexecuted by the one or more processors, cause the one or more processorsto perform operations for accessing data provided in a first system by adatabase (DB)-based analytics engine of a second system, the operationscomprising: retrieving data metadata associated with data stored withina database system of an enterprise, the data metadata being provided ina first format and being used by the first system to store and accessthe data, the data metadata describing how data is stored within thefirst system and comprising entity definitions and relationships betweenentities; providing, by a metadata provider executed within the firstsystem, a metadata document including the data metadata provided in aninteroperable format transformed from the first format, theinteroperable format being unbound to any analytics engine; receiving,by integration services executed within a cloud service, the metadatadocument in response to a request issued by the integration services tothe first system; processing, by a deployer of the integration services,the metadata document to provide analytics metadata in a second format,the analytics metadata comprising one or more of data definitionlanguage (DDL) statements and data modification language (DML)statements, the analytics metadata being stored in the second system andbeing specific to the DB-based analytics engine to be consumable by theDB-based analytics engine to access the data from the database system ofthe enterprise; and retrieving, by the DB-based analytics engine, thedata from the database system of the enterprise based on the analyticsmetadata to provide analytics data based on the data.
 9. Thenon-transitory computer-readable storage medium of claim 8, wherein thedata metadata is retrieved in response to the data being marked as to beaccessible to the DB-based analytics engine.
 10. The non-transitorycomputer-readable storage medium of claim 8, wherein the data metadatais retrieved in response to determining that a change to the datametadata has occurred.
 11. The non-transitory computer-readable storagemedium of claim 8, wherein the DB-based analytics engine is executedwithin the database system of the enterprise.
 12. The non-transitorycomputer-readable storage medium of claim 8, wherein the DB-basedanalytics engine is executed within a cloud-based database system thataccesses the database system of the enterprise.
 13. The non-transitorycomputer-readable storage medium of claim 8, wherein the deployer isprovided within the database system of the enterprise.
 14. Thenon-transitory computer-readable storage medium of claim 8, wherein theinteroperable format comprises core schema notation (CSN).
 15. A system,comprising: a computing device; and a non-transitory computer-readablestorage device coupled to the computing device and having instructionsstored thereon which, when executed by the computing device, cause thecomputing device to perform operations for accessing data provided in afirst system by a database (DB)-based analytics engine of a secondsystem, the operations comprising: retrieving data metadata associatedwith data stored within a database system of an enterprise, the datametadata being provided in a first format and being used by the firstsystem to store and access the data, the data metadata describing howdata is stored within the first system and comprising entity definitionsand relationships between entities; providing, by a metadata providerexecuted within the first system, a metadata document including the datametadata provided in an interoperable format transformed from the firstformat, the interoperable format being unbound to any analytics engine;receiving, by integration services executed within a cloud service, themetadata document in response to a request issued by the integrationservices to the first system; processing, by a deployer of theintegration services, the metadata document to provide analyticsmetadata in a second format, the analytics metadata comprising one ormore of data definition language (DDL) statements and data modificationlanguage (DML) statements, the analytics metadata being stored in thesecond system and being specific to the DB-based analytics engine to beconsumable by the DB-based analytics engine to access the data from thedatabase system of the enterprise; and retrieving, by the DB-basedanalytics engine, the data from the database system of the enterprisebased on the analytics metadata to provide analytics data based on thedata.
 16. The system of claim 15, wherein the data metadata is retrievedin response to the data being marked as to be accessible to the DB-basedanalytics engine.
 17. The system of claim 15, wherein the data metadatais retrieved in response to determining that a change to the datametadata has occurred.
 18. The system of claim 15, wherein the DB-basedanalytics engine is executed within the database system of theenterprise.
 19. The system of claim 15, wherein the DB-based analyticsengine is executed within a cloud-based database system that accessesthe database system of the enterprise.
 20. The system of claim 15,wherein the deployer is provided within the database system of theenterprise.